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(54) Server computer providing integrity of files stored in it 



(57) The problem of the vulnerability of electronic 
content stored on server computers to alteration by un- 
authorised third parties is one which has become much 
exacerbated with the advent of the Internet and the 
World Wide Web. Present day approaches, including 
approaches based on digital signature techniques, al- 
low for the checking of content transmitted over com- 
munications networks to, for example, client computers, 
to establish if tampering by unauthorised third parties 
has occurred. Such approaches all suffer from the dis- 
advantage that any content which has been tampered 
with is still transmitted over the network to the client 
computer before such a check takes place. According 



to the invention however, a server computer storing 
computer files, each computer file having an associa ted 
u nique digital signature, receiving requests for access 
t oj>ne or more such computer files, only allows access 
t QThe or each computer file if their associated digital sig- 
n atures are valid. Thus, if a computer file has been tam- 
pered with by an unauthorised third party, the digital sig- 
nature associated with that computer file will prove to 
be invalid when checked and the server computer will 
not serve the computer file at all. In this way, a computer 
file that has been tampered with can never leave the 
server computer, much improving the security of the 
stored computer files. 
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Description 

[0001] The present invention relates to a method of 
and apparatus for the serving of computer files. It has 
application, in particular, to the secure serving of digit- 
ally signed computer files. 

[0002] The notion of associating a sign of some form 
with a document or an object to denote, for example, 
authorship or ownership has long been in existence. It 
is an unfortunate reflection on human nature that the re- 
lated notion of falsely associating a sign with a docu- 
ment or with an object to indicate false authorship or 
ownership has also long been in existence. 
[0003] With the advent of the printing press and the 
printed document and, more recently, the digital or elec- 
tronic computer and the digital or electronic document, 
the problems of the faithful reproduction and the con- 
venient editing or alteration of documents have been 
much ameliorated. 

[0004] As will be well known, a digital document can 
typically be altered or copied as many times as is wished 
without any change in quality since it is onty the digital 
bits representing the information content of the docu- 
ment that are changing. If a digital document is created 
by a first party and then covertly altered by a second 
party, it may well be difficult for a third party subsequent- 
ly reading the document to tell that it has been altered. 
[0005] The advent of networked communication be- 
tween computers and in particular the rise of the I ntemet 
and the World Wide Web has meant that vast numbers 
of computers all over the world can now communicate 
with each other using common protocols. Electronic 
documents are often now made available as Web Pages 
on a ) Web Site. 

[0006] It will be well known that the World Wide Web 
(or simply "Web' hereinafter) has a wide variety of asso- 
ciated concepts and standards. A rich source of infor- 
mation relating to these concepts and standards is the 
World Wide Web Consortium (http://www.w3c.org), a 
body hosted by the Laboratory for Computer Science at 
the Massachusetts Institute of Technology (MIT). Con- 
cepts such as a 'Web Server 1 , a "Web Site', a Web 
Page', a "Web Browser*, a 'Hyperlink 1 and a 'Uniform Re- 
source Locator 1 and standards such as 'Hypertext 
Markup Language will be well known. 
[0007] A problem faced by those parties wishing to 
distribute content in the form of electronic documents or 
files, for example, on the World Wide Web, has been the 
vulnerability of the stored content to deliberate alteration 
by unauthorised third parties accessing the content over 
a communications network. 

[0008] Should an unauthorised third party manage to 
access a given Web Server, they might, for example, 
edit a Web Page stored on that Web Server. When the 
Web Page is subsequently viewed with a Web Browser, 
the content of the Web Page would then reflect the mes- 
sage of the unauthorised third party rather than the orig- 
inal content provider. 



[0009] It will be appreciated that a wide variety of mo- 
tives may exist for unauthorised third parties to attempt 
to subvert the message delivered by a given piece of 
content but it is probably safe to assume that in all cases 

5 the content provider would prefer not to have the mes- 
sage delivered by its content tampered with and then 
presented to the browsing world as its own. 
[0010] A first present day approach to tackling this 
problem of the vulnerability of stored content to altera - 

io tion by unauthorised third parties might attempt to en- 
sure that the stored content is never accessible to un- 
authorised third parties. 

[0011] One example of this approach is the use of a 
so-called firewall'. As will be well known a firewall may 

15 be used to protect a computer connected to a network 
by controlling traffic between the computer and the net- 
work such that only certain types of traffic, as defined 
by the computer administrator, are allowed to pass front 
the network to the computer or vice versa. In theory this 

20 should prevent unauthorised third parties from access- 
ing the computer from the network such that they could 
alter the content stored on that computer. Naturally such 
a firewall cannot protect the stored content from altera- 
tion by a malicbus user validly operating inside the fire- 

25 wall 

[0012] In practice it will be well known that real-world 
implementations of firewalls are often far from secure. 
[0013] A second approach, mindful of the fact that the 
content might have been altered either when stored or 
30 during transmission over a communications channel, is 
to perform a check on downloaded content to see if it 
has been tampered with. 

[0014] One simple example of this second approach 
is the use of a so-called 'checksum'. As will be well 

35 known a checksum is computed from a given block of 
data, yielding a value which is then associated with that 
block of data. If the checksum computation is run again, 
any change in the data will cause a change in the check- 
sum value. Checksum methods are most often em- 

40 ployed as a simple check to detect corruption during 
transmission of data. In theory then, when a given piece 
of content is downloaded along with an initial checksum 
value, a new checksum value can be computed for the 
downloaded content, which can then be compared with 

45 the original checksum value sent along with the content. 
If the original checksum value and the newly derived 
checksum value are the same then there may be some 
confidence that the content has not been altered after 
the computation of the original checksum value, which 

50 might be either whilst stored or during transmission. 
[0015] In practice it will be appreciated however, that 
any unauthorised third party able enough, for example, 
to access and tamper with stored content may well be 
able enough to alter the original checksum accordingly. 

55 if this were done then the checksum comparison per- 
formed when the content is downloaded would falsely 
indicate that the content had not been tampered with 
since its original storage. 
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[0016] More sophisticated examples of this second 
approach involve the use of so-called 'digital signa- 
tures*. The theory and practice of digital signatures have 
become very well known over the past few years as the 
Internet and more particularly the World Wide Web have 
experienced exponential growth. 
[0017] A treatment of digital signatures may, for ex- 
ample, be found in 'Applied Cryptography: Protocols, Al- 
gorithms and Source Code in C by Bruce Schneier, sec- 
ond edition 1996, John Wiley & Sons. A further treat- 
ment of digital signatures may be found in 'PGP: Pretty 
Good Privacy* by Simson Garfinkel, first edition 1995, 
O'Reilly & Associates. Terms such as 'public key*, 'pri- 
vate key*, 'hash function' and 'message digest function' 
will be well understood. 

[0018] Digital signature techniques utilise so-called 
'public key* cryptographic methods. As will be well 
known, public key cryptography uses an algorithmically 
related pair of keys, a so-called 'public key* and a so- 
called 'private key 1 , to encrypt messages, rather than the 
single key of more traditional symmetric key cryptogra- 
phy. The public key is intended to be widely distributed 
in the public domain whereas the private key must be 
kept absolutely secret. Crucially, knowledge of the pub- 
lic key does not allow the private key to be determined. 
Typically, a message encrypted with a public key is de- 
crypted and can only be decrypted with the correspond- 
ing private key. The encryption process is symmetric 
however such that an encryption operation performed 
with the private key can be decrypted with the public key. 
A successful decryption with a given public key guaran- 
tees that the message was encrypted with the matched 
private key. 

[0019] Public key cryptography can be used to at- 
tempt to secure a communications channel such that 
content transmitted over that channel cannot be inter- 
cepted and compromised. One example of such an ap- 
plication is the Secure Sockets Layer (SSL) protocol, 
originally developed by the Netscape Communications 
Corporation (Mountain View CA, USA). For communi- 
cation between, for example, a client computer and a 
server computer, such a protocol first authenticates the 
server computer using public key cryptography and then 
shares a symmetric key for use in encrypting all further 
communication between the client and server comput- 
ers. A protocol such as SSL thus both protects against 
a first server computer pretending to be a second server 
computer and serving data falsely purporting to be from 
that second server computer and prevents any unau- 
thorised third party intercepting and altering communi- 
cations during transmission. Such a protocol is, howev- 
er, aimed at the securing of content during transmission, 
not at solving the problem of the stored content being 
vulnerable to alteration. 

[0020] Digital signature techniques using public key 
cryptography allow checks not only as to 'authentica - 
tion', gua ranteeing that a digitally signed 'docume nt' 
cfc*Ss in fact originate from the party whose signature the 



document bears but also as to 'integrity 1 , guaranteeing 
t fiaTthe contents of the document have not been tam- 
pered with since the originating party digitally signed the 
document. 

s [0021] The process by which digital signatures are 
employed in order to perform a check on downloaded 
content to see if it has been tampered with will be dis- 
cussed below in greater detail having regard to the in- 
vention. It will suffice at this point to consider the func- 

10 tionality provided through the use of digital signatures 
in the following example of the second approach. 
[0022] The Microsoft Corporation (Redmond WA, 
USA) has developed so-called 'Authenticode™ '. Au- 
thenticode™ software is installed on client computers 

*5 and is directed towards checking software that has been 
downloaded over a network from, for example, a server 
computer, to see if the software has been tampered with 
in an unauthorised fashion. Each such piece of code will 
have been digitally signed. Having regard to a particular 

20 piece of digitally signed code downloaded over a net- 
work, before the installation or execution of the code, 
Authenticode™ may check the digital signature to see if 
it is valid. A selection of a 'high', 'medium* or 'none' Au- 
thenticode™ safety setting must be made in the client 

& software. With a 'high' setting Authenticode™ will not al- 
low the installation or execution of code whose associ- 
ated digital signature proves to be invalid. With, howev- 
er, a 'medium' setting, Authenticode™ will warn the user 
that the code is 'untrustworthy' but will allow the option 

30 of installing or executing it if the user wishes. With a 
safety setting of 'none', Authenticode™ provides no such 
warning. 

[0023] As will be evident, an arrangement such as Au- 
thenticode™, checking code downloaded to a client at 

35 that client, can only go so far in protecting stored con- 
tent. Such checking performed at the client will involve 
the sending of the content in question to the client com- 
puter. In this way, content that has been tampered with 
will still be sent out over the network to the client It may 

40 be that an arrangement such as Authenticode™ may be 
configured to deny the installation or execution of an 'un- 
trustworthy* piece of code, but the code still exists at the 
client and it cannot be guaranteed that an able enough 
user could not access it. Alternatively, it is clear that such 

45 a configuration can be changed to allow the installation 
or execution of 'untrustworthy 1 code if so wished. 
[0024] It will be appreciated that neither with the first 
approach to the problem of the content alteration (at- 
tempting to ensure that the stored content is never ac- 

50 cessible to unauthorised third parties), nor with the sec- 
ond approach, (attempting to perform a check on down- 
loaded content to see if it has been tampered with), is it 
guaranteed that the altered content will not be seen. 
[0025] In the first case if, for example, the relevant 

55 firewall had been breached and unbeknownst to the 
Web Site administrator the stored content had been al- 
tered, the altered content would be viewed by anyone 
accessing the Web Page until such time as the Web Site 
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administrator noticed or was informed of the alteration 
and took corrective action. 

[0026] In similar fashion, in the second case if, for ex- 
ample, the digital signature authentication of the rele- 
vant downloaded content had failed, then, as mentioned 
above, although the content will be deemed 'untrustwor- 
thy 1 , it may well be open to the •downloaded to view or 
otherwise execute the 'untrustworthy 4 altered content. 
Indeed, a situation can be imagined where the notoriety 
of a Web Page that had been tampered with by an un- 
authorised third party is the very reason for persons 
wanting to view the Web Page, before the Web Site ad- 
ministrator can take corrective action. Again, even if the 
downloader is prevented from, for example, executing 
an untrustworthy file, that file has still been sent out over 
a network and it may well be possible to access a copy 
of the file at some point in the process. 
[0027] I n contrast with these present day approaches 
however, according to the invention there is provided a 
server computer comprising: 

means arranged to store one or more computer 
files; 

means arranged to store one or more digital signa- 
tures; 

each computer file having an associated digital sig- 
nature; 

means arranged to allow a connection between the 
file server computer and at least one other compu- 
ter; 

means arranged to receive requests from another 
computer for access to at least one computer file 
stored on said server computer; 

means arranged to retrieve the or each requested 
computer file; 

means arranged to retrieve the digital signature as- 
sociated with the or each requested computer file; 

means arranged to validate the digital signature as- 
sociated with the or each requested computer file; 
and 

means arranged to provide said other computer 
with access to the or each requested computer file 
only when the digital signature associated with the 
or each respective requested computer file is valid. 

[0028] Advantageously, in this way it is assured that 
if the computer file storage security is breached and one 
or more files tampered with, it will not be possible for 
any external party to see the results of the tampering. 
No copy of a computer file can leave the file server com- 



puter where it is stored, unless the digital signature as- 
sociated with that computer file has been validated. If 
the file has been tampered with, then no external third 
party will ever be able to obtain a copy of it. There can 
5 be no possibility of the message or functionality of the 
original computer file being subverted by an unauthor- 
ised third party to their own ends. 
[0029] A method of operating a server computer is al- 
so provided. 

10 [0030] An embodiment of the invention by way of ex- 
ample will now be discussed with reference to the ac- 
companying drawings in which: 

Figure 1 A represents first and second conventional 
is computers connected to a communications net- 
work; 

Figure 1B represents such a conventional compu- 
ter; 

20 

Figure 2 illustrates a procedural flowchart for the 
digital signing of a digital document; 

Figure 3 illustrates the entities involved in the proe- 
ms ess of Figure 2; 

Figure 4 illustrates a procedural flowchart for the 
serving of digitally signed documents; 

so Figure 5 illustrates a procedural flowchart for the au- 
thentication of the digital signature of a digitally 
signed document; and 

Figure 6 illustrates the entities involved in the proc- 
35 ess of Figure 5. 

[0031] Figure 1A illustrates a conventional general 
purpose computer 100, suitable for use as a Web Serv- 
er. Such a computer 100 is illustrated in Figure 1 B and 

40 will typically have at least a central processing unit 
(CPU) 102, readonly memory (ROM) 104, random-ac- 
cess memory (RAM) 106, a storage device such as a 
hard disk 108, a device for reading from and writing to 
storage media such as a floppy disk drive 110 for read- 

4S ing from and writing to floppy disks and input and output 
ports 112 for connection to other devices or communi- 
cations networks. 

[0032] Returning to Figure 1 A, a floppy disk 114 is 
indicated for the floppy disk drive 110 to read from or 

so write to. The computer 1 00 is connected to a communi- 
cations network 116, which in this embodiment is to be 
understood as the well known Internet. A second con- 
ventional general purpose computer 118, suitable for 
use as a Web Client, is similarly connected to the Inter- 

55 net communications network 116. 

[0033] The computer 1 00 may utilise any suitable op- 
erating system, well known examples being Microsoft 
Windows™ NT , Linux or any one of the other many ver- 
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sions of Unix. Application programs may be written in 
any of many well known suitable languages in which to 
write application programs, one well known example of 
which is C++. Such an operating system and application 
programs may be loaded onto the storage device 108 s 
of the computer 100. 

[0X194] The functionality disclosed in accordance with 
this embodiment of the invention may be implemented 
as a software module application program to be execut- 
ed by the computer 100. This software application pro- 
gram may then be stored in any suitable computer read- 
able storage media form, for example on floppy disk 114, 
for loading into the computer 100, via the floppy disk 
drive 110, for execution. A well known alternative would 
be to store the software application on a CD-ROM (not 
shown) for loading into the computer 1 00 via a CD-ROM 
drive (not shown) for execution. A further well known al- 
ternative would be to download the software application 
program over the network 1 1 6, for execution by the com- 
puter 100. 

[0035] I n this embodiment the computer 1 00 has one 
or more software application programs loaded onto it 
which, when executed, will cause the computer 100 to 
operate as a Web Server. One or more Web Documents 
will be stored on the appropriate storage device of the 
Web Server, as is conventional. 
[0036] One or more software application programs 
loaded onto the second computer 108, including a Web 
Browser program, when executed, enable communica- 
tion using World Wide Web protocols and in particular 
allowthe viewing of Web Pages, for example those host- 
ed on the Web Server computer 100, using a Web 
Browser 

[0037] A conventional digital signing process will now 
be discussed having regard to Figures 2 and 3. It will be 
appreciated that the structure of Figures 2 and 3 is mir- 
rored; Figure 2 illustrates a procedural flowchart of the 
process of the digital signing of a digital or electronic 
document whilst Figure 3 illustrates in simple fashion the 
behaviour of the corresponding entities. It will be further 
appreciated that the steps indicated in the procedural 
flowchart will be carried out through execution of the 
software application running on the Web Server 100. 
[0038] By way of example in this embodiment, the 
Web Documents considered are Web Pages, typically 
HyperText Markup Language (HTML) documents, 
stored on the appropriate storage device of the Web 
Server 100, in this example, the hard disk. It is to be 
noted however that this example is non-limiting; many 
other forms of computer file are equally able to be treat- 
ed according to the invention (including, for example, 
documents of formats other than HTML, images in, for 
example, Joint Photographic Experts Group (JPEG) for- 
mat and downloadable software programs). 
[0039] In first step 200 a document is selected for dig- 
ital signing. Such a document 300 is illustrated in Figure 
3. 

[0040] In a second step 202, the document to be 



signed is run through a so-called 'hash' function. The 
hash function derives a short representation of the doc- 
ument, which is often referred to as the 'hash' of the doc- 
ument. The document to be signed 300 and the hash of 
the document to be signed 302 are figuratively illustrat- 
ed in Figure 3. The hash function and the hash of the 
document are often alternatively referred to as the 'mes- 
sage digest* function and the 'message digest' respec- 
tively. Two well known examples of hash functions are 
the MD5 and SHA hash functions. 
[0041] It will be well known that the hash of a docu- 
ment produced by a hash function is remarkably sensi- 
tive to the contents of the document. If, for example, a 
text document is altered by so much as the insertion of 
a full stop, then a hash generated before the insertion 
of the full stop and a hash generated after the insertion 
of the full stop will, in general, be completely different. 
[0042] In a third step 204, a digital signature is created 
by encrypting the hash of the document using a private 
key It will be appreciated that this private key might be 
the private key of any of a number of parties including, 
for example, the creator of the content, the owner of the 
content or the administrator of the content. The notion 
of an approved signing party with associated approved 
keys will be discussed below The hash of the document 
to be signed 302 and the digital signature 304 are illus- 
trated in Figure 3. 

[0043] Once so created, the digital signature for the 
document to be signed may be stored on the appropriate 
storage device of the Web Server 100, in this example, 
the hard disk. 

[0044] Alternatively in an optional fourth step 206, the 
digital signature so created is appended to the docu- 
ment to be signed to create a digitally signed document. 
The digitally signed document 306 is illustrated in Figure 

3. The digitally signed document can then be stored on 
the appropriate storage device of the Web Server 100, 
in this example, the hard disk. 

[0045] A document serving process according to the 
invention wilt be discussed having regard to Figures 1, 

4, 5 and 6. Again, it will be appreciated that steps indi- 
cated in the procedural flowcharts will be carried out 
through execution of the software application running on 
the Web Server 100. 

[0046] Having regard to Figures 1 and 4, in a first step 
400, the Web Server 100 receives a request from the 
second computer 114 for access to a given Web Page 
stored on the Web Server 100. As will be well known, 
this request will typically be initiated through the user of 
the second computer 114 clicking on a hyperlink, the 
Uniform Resource Locator (URL) of which points to the 
given Web Page. 

[0047] In a second step 402, the Web Page corre- 
sponding to the URL request is retrieved from the ap- 
propriate storage device of the Web Server 100, in this 
example, the hard disk. 

[0046] In a third step 404 the digital signature corre- 
sponding to that Web Page is also retrieved from the 
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appropriate storage device of the Web Server, in this 
example, the hard disk. It will be appreciated that if the 
digital signature had already been appended to the doc- 
ument in accordance with optional step 206 above, then 
this step would be performed upon retrieval of the doc- 
ument itself. 

[0049] In a fourth step 406, the digital signature asso- 
ciated with the document is validated. 
[0050] A procedural flowchart of the process of digital 
signature validation is illustrated in Figures 5 and 6. This 
process of digital signature validation provided for in 
step 406 will now be discussed having regard to Figures 
5 and 6 before returning to discussion of the steps as 
illustrated in Figure 4. It will be appreciated that the 
structure of Figures 5 and 6 is mirrored; Figure 5 illus- 
trates a procedural flowchart of the process of digital sig- 
nature validation whilst Figure 6 illustrates in simple 
fashion the behaviour of the corresponding entities. 
[0051] Having regard to Figure 5, in a first step 500, 
the digital signature associated with the document is de- 
crypted with a public key, in this case the public key cor- 
responding to the private key first used to sign the hash 
or message digest of the document. As will be well 
known this decryption will yield the hash of the docu- 
ment. The digital signature 600 associated with the re- 
quested document and the hash 602 obtained through 
the decryption are illustrated in Figure 6. 
[0052] In a second step 502, the document is again 
run through the same hash function as was originally 
used in the process of digitally signing the document. In 
this way a new hash of the document is derived. The 
document 604 and the new hash of the document 606 
are illustrated in Figure 6. 

[0053] It will be appreciated that if the public key used 
to decrypt the digital signature associated with the re- 
quested document was not the matched public key for 
the private key used to sign the hash of the document, 
then the digital signature will not decrypt correctly. As a 
consequence, the hash of the document obtained 
through the decryption will not be the correct one and 
will not be the same as the new bash of the document. 
Similarly, it will be further appreciated that if the docu- 
ment has been altered inbetween the signing of the doc- 
ument including the generation of the hash and the gen- 
eration of the new hash then the hash and the new hash 
will not be the same. 

[0054] Consequently, in a third step 504, the hash of 
the document and the new hash of the document are 
compared. The comparison of the hash of the document 
602 and the new hash of the document 606 is figurative- 
ly illustrated in Figure 6. 

[0055] If the hash and the new hash are identical then 
not only is it guaranteed that the party considered to 
have signed the document did in fact sign the document 
(i.e. the public key used in the decryption correctly 
matched the private key used to sign to document) but 
it is also guaranteed that the document has not been 
altered since generation of the digital signature (i.e. the 



hash of the document and the new hash of the document 
are identical). The comparison of the hash of the docu- 
ment and the new hash of the document returns a result 
to the authentication question posed in step 406. The 

s digital signature associated with the requested docu- 
ment either passes the validation test or it does not. 
[0056] Discussion of the document serving process 
may now return to a consideration of Figure 4. 
[0057] If the digital signature is validated then, in a fifth 

io step 408, the Web Server proceeds to send the Web 
Page to the requesting party, in conventional fashion. 
[0056] It is to be noted that, in a more general case, 
once the digital signature associated with a computer 
file has been validated, the server computer could allow 

* 5 access to the computer file other than sending the whole 
file at once to the client computer. By way of example, 
the server computer might instead open a communica- 
tion session with the client computer and stream por- 
tions of the file to the client computer as required. 

20 [0059] If the digital signature is not validated however, 
which is to say that either the document has been al- 
tered since the digital signature associated with that 
document was created or that the document was in fact 
signed by someone other than who was represented as 

25 having signed the document, then the Web Server will 
not proceed to send the document at all. Instead, in a 
sixth step 410, the Web Server will send a Web Page to 
the requesting party informing them that the Web Page 
that they have requested is not available. 

30 [0060] In a seventh step 412, the Web Server might, 
for example, send a message to a system administrator, 
containing a warning as to the invalid digital signature. 
[0061] It is to be noted that, at the present time, public 
key operations are relatively slow, being of the order of 

35 100 to 1000 times more slow than hash functions or 
symmetric key operations. If a Web Server were to be 
checking the digital signatures in respect of every doc- 
ument served, it will be appreciated that this might quick- 
ly become a performance bottleneck. To ameliorate this 

40 problem, it is possible to use dedicated hardware boards 
optimised for the checking of digital signatures. One ex- 
ample of such a board is the one produced by nCipher 
of Cambridge, United Kingdom. Each such board will 
typically allow the checking of several hundred digital 

45 signatures per second, with the possiblity of daisy- 
chaining further boards as required. 
[0062] As mentioned above, it is quite possible that 
there will be a number of parties who might wish to dig- 
itally sign one of 'their 1 documents. Each such party will 

50 have their own private key with which to perform the rel- 
evant encryption. It will thus be necessary to provide a 
means by which each digitally signed file can be asso- 
ciated with the relevant signing party such that the ap- 
propriate matched public key can be used for the digital 

55 signature authentication. 

[0063] One example of a means by which each digit- 
ally signed file may be associated with the signing party 
is simply to attach a copy of the digital certificate of the 
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signing party to the digitally signed file. Having regard 
to Figure 2, this might, for example, be performed in a 
further step following step 206. The well-known concept 
of the digital certificate, closely related to that of the dig- 
ital signature, will not be discussed in any detail here. It 
will suffice to note that a digital certificate binds the iden- 
tity of a party to the public key of that party and is itself 
signed by a third party, usually denoted a Trusted Third 
Party (TTP). 

[0064] In this way, having regard to Figure 4, when a 
digitally signed file is retrieved in steps 402 and 404, the 
attached digital certificate would also be retrieved. The 
digital certificate will provide the identity of the signing 
party and the associated public key of the signing party. 
Having regard to Figure 5, this public key may then be 
used in step 500, to obtain the hash of the digitally 
signed document as required in the authentication proc- 
ess. 

[0065] If the digital certificate attached to the file is not 
the digital certificate of the signing party then the au- 
thentication will fail. It is possible to consider however 
that an unauthorised third party manages to smuggle a 
digitally signed file onto the Web Server with a matched 
digital certificate. A subsidiary problem which therefore 
arises is the controlling of which parties are authorised 
to sign documents for storing on that particular Web 
Site. 

[0066] A list of authorised signing parties may be con- 
structed and stored on the Web Server; only the digital 
certificates of the authorised signing parties may be val- 
idly used. Since the next point of attack for an unauthor- 
ised third party would be to try and add a false 'author- 
ised' signing party to the list, this list may itself be se- 
cured by signing it with the private key of the system 
administrator. In this way, the list can only be read using 
the public key of the system administrator which en- 
sures, as with the discussion of the stored documents 
above, that the list has not been tampered with and does 
in fact originate from the system administrator. 
[0067] Another issue which may be of interest is the 
ensuring that documents with a limited 'life' are not 
served after a predetermined time or date. Having re- 
gard to Figure 2, this might be achieved, in a further step 
following step 206, through the attachment of an ' expiry 
time- or date-stamp' to the digitally signed file. To pre- 
vent this expiry time-stamp being compromised, the dig- 
itally signed document with the attached expiry time- 
stamp might itself be signed in a vet further step with, 
for example, the private key of the system administrator. 
[0068] Having regard to Figure 4, in this instance 
when the digitally signed document is retrieved, in steps 
404 and 404, the digitally signed document would have 
the expiry time-stamp attached and would be signed by 
the system administrator. In a further step then, the ex- 
piry time-stamp could first be retrieved through the de- 
cryption of the digitally signed document with the public 
key of the system administrator. In a yet further step, a 
check could then be performed to see if the relevant time 



or date had been passed. If the relevant time or date 
had been passed then the document would not be 
served. 

[0069] A simple application of this embodiment ac- 
s cording to the invention will now be discussed. The Web 
Server illustrated in Figure 1 is taken to host a corporate 
Web Site. The Web Server will typically be protected by 
a corporate firewall as discussed above. Public comput- 
ers having an Internet connection and being suitably 
10 equipped with Web Browsers might then be used to view 
Web Pages on this corporate Web Site. As will be well 
known these Web Pages might typically be used to 
present information about the company to the world at 
large. 

15 [0070] A first situation might be considered where the 
company posts a document in the form of a Web Page 
on its corporate Web Site. The document has been dig- 
itally signed using the private company key in accord- 
ance with the above discussion of Figures 2 and 3. A 

20 member of the public requests access to this document, 
typically by clicking on the hyperlink associated with the 
document. In accordance with the above discussion of 
Figures 4,5 and 6, the Web Server carries out an au- 
thentication of the digital signature of the document. In 

2S this first situation the authentication is successfully car- 
ried out and the Web Page served to the member of the 
public making the request without further ado. 
[0071] A second situation might now be considered 
where again the company posts a document in the form 

30 of a Web Page on its corporate Web Site. The document 
has been digitally signed using, for example a private 
company key in accordance with the above discussion 
of Figures 2 ana 3. in this situation however, unbe- 
knownst to the corporate Web Site administrator, the 

35 corporate firewall has been compromised and an unau- 
thorised third party has gained access to the Web Serv- 
er. Using this access, the unauthorised third party has 
then proceeded to alter one or more of the Web pages 
stored on the Web Server. The alterations effected by 

40 this unauthorised third party will depend on their motives 
for mounting such an attack; it is however unfortunately 
easy to conceive of a range of such motives from pranks 
to outright sabotage. 

[0072] A member of the public might now be consid- 
45 ered as requesting access to a document which has 
been altered by the unauthorised third party. In accord- 
ance with the above discussion of Figures 4,5 and 6, the 
Web Server carries out an authentication of the digital 
signature of the document. In this second situation the 
50 authentication will fail due to the mismatch in the hash 
of the document and the new hash of the document. 
[0073] The Web Page will therefore not be served to 
the member of the public making the request. Crucially, 
it will therefore not be possible for the member of the 
55 public making the request to see the altered document 
at all. 

[0074] As indicated above, if the Web Page altered to 
suit the motives of an unauthorised third party intruder 
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were allowed to be served to the member of the public 
making the request, albeit with a warning that the doc- 
ument was 'untrustworthy', then damage could nonethe- 
less be done to the company's business or reputation. 
[0075] A third situation might now be considered. In 
this situation, again unbeknownst to the corporate Web 
Site administrator, the corporate firewall has been com- 
promised and an unauthorised third party has gained 
access to the Web Server. Using this access the unau- 
thorised third party has posted a forged document in the 
form of a Web Page on the corporate Web Site of the 
company. The document has been digitally signed by 
the third party in accordance with the above discussion 
of Figures 2 and 3 but the private key used in the signing 
process was one selected by the unauthorised third par- 
ty rather than that of the company. 
[0076] A member of the public might now be consid- 
ered as requesting access to a document which has 
been altered by the unauthorised third party. In accord- 
ance with the above discussion of Figures 4,5 and 6, the 
Web Server carries out an authentication of the digital 
signature of the document. In this third situation the au- 
thentication will again fail. An attempt to decrypt the dig- 
ital signature with the company public key when the dig- 
ital signature was signed with an unauthorised third par- 
ty private key will again cause a mismatch to occur in 
the hash of the document and the new hash of the doc- 
ument. 

[0077] Yet again the Web Page will therefore not be 
served to the member of the public making the request 
and again, crucially, it will therefore not be possible for 
the member of the public making the request to see the 
altered document at all. 



Claims 

1 . A server computer comprising: 

means arranged to store one or more computer 
files; 

means arranged to store one or more digital 
signatures; 

each computer file having an associated digital 
signature; 

means arranged to allow a connection between 
the file server computer and at least one other 
computer; 

means arranged to receive requests from an- 
other computer for access to at least one com- 
puter file stored on said server computer; 

means arranged to retrieve the or each re- 
quested computer file; 



means arranged to retrieve the digital signature 
associated with the or each requested compu- 
ter file; 

s means arranged to validate the digital signature 

associated with the or each requested compu- 
ter file; and 

means arranged to provide said other computer 
10 with access to the or each requested computer 

file only when the digital signature associated 
with the or each respective requested computer 
file is valid. 

^ 2. A server computer as claimed in claim 1 , in which 
said means arranged to provide said other compu- 
ter with access to the or each requested computer 
file only when the digital signature associated with 
the or each respective requested computer file is 

20 valid comprises means arranged to provide to said 
other computer a copy of the or each computer file 
only when the digital signature associated with the 
or each respective requested computer file is valid. 

25 3. a server computer as claimed in claim 1 or claim 2 
further comprising: 

means arranged to store a list of approved com- 
puter file signing parties; 

30 each computer file signing party having at least 

one associated signing key with which to create 
digital signatures; and in which 
said means arranged to validate the digital sig- 
nature associated with the or each requested 

35 computer file only validates said digital signa- 

ture if said digital signature was created with a 
signing key associated with an approved com- 
puter file signing party. 

40 4. A server computer as claimed in any one of claims 
1 to 3 further comprising a clock, wherein the or 
each computer file stored on said server computer 
has an associated expiry date; such that: 

said means arranged to validate the digital 

45 signature associated with the or each requested 
computer file only validates said digital signature if 
the expiry date associated with the or each compu- 
ter file is later than the current clock date. 

so s. A server computer arranged to store one or more 
computer files, one or more digital signatures, each 
computer file having an associated digital signa- 
ture, said server computer being arranged to per- 
form the operation of: 

55 

receiving a connection from another computer; 
receiving a request from said other computer 
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for access to at least one computer file stored 
on said server computer; 

retrieving the or each requested computer file; 

5 

retrieving the digital signature associated with 
the or each requested computer file; 

validating the digital signature associated with 
the or each requested computer file; and 10 

providing said other computer with access to 
the or each requested computer file only if the 
digital signature associated with the or each re- 
quested computer file is valid. is 

A method of operating a server computer compris- 
ing: 

receiving a connection from another computer; 20 

receiving a request from said other computer 
for access to at least one computer file stored 
on said file server computer; each said compu- 
ter file having an associated unique digital sig- 2s 
nature stored on said file server computer; 

retrieving the or each requested computer file; 

retrieving the digital signature associated with &> 
the or each requested computer file; 

validating the unique digital signature associat- 
ed with the or each requested computer file; 
and 35 

providing said other computer with access to 
the or each requested computer file only if the 
digital signature associated with the or each re- 
quested computer file is valid. 40 
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